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Introduction 


This  report  summaries  results  of  the  research  carried  out  within  the  last  phase  of  the  project  contract 
no.:  F61775-99-WE099  -  Multi-Agent  Systems  in  Communications  (MASiC).  Results  outlined  in  the 
report  are  accompanied  by  a  multi- agent  system  prototype  that  was  a  subject  of  the  testing. 

MASiC  research  effort  aimed  at  identifying  mechanisms  for  saving  communication  traffic  in  multi¬ 
agent  systems.  Within  the  first  phase  of  the  research  project  [Pechoucek  00b]  we  have  designed  a  tri¬ 
base  acquaintance  model  (3bA)  as  a  formal  model  of  agent's  mutual  awareness.  Within  the  second 
phase  [Pechoucek  00c]  we  have  implemented  an  agent  with  a  3bA  model  (tri-base  agent)  that  has 
been  incorporated  within  the  ProPlanT  —  multi-agent  system.  The  last  phase  has  been  devoted  to 
experimenting  with  the  system,  justifying  the  proposed  methodology  and  suggesting  spots  where  the 
overall  performance  of  the  tri-base  acquaintance  model  may  be  improved  by  machine  learning 
techniques. 

This  report  starts  with  brief  summary  on  the  philosophy  of  the  3bA  model  and  discussion  of  its 
contribution  in  communication  savings  in  a  multi-agent  system.  After  that  we  show  experimental 
results  we  have  achieved  on  testing  a  sample  community.  The  report  concludes  with  a  study  of 
possible  utilization  of  machine  learning  techniques  in  communication  efficiency  improvements.  The 
appendix  provides  a  user  documentation  to  the  experimental  demonstration  Java-based  3bA  agent 
within  the  ProPlanT  multi- agent  environment. 
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Acquaintance  Model  Communication  Savings 


This  report  is  a  part  of  the  overall  MASiC  project  documentation.  The  MASiC  phase  1  report 
[Pechoucek  00b]  is  a  prerequisite  for  thorough  understanding  of  this  study.  The  Tri-base 
Acquaintance  Model  (3bA)  is  a  formal  model  of  agents'  mutual  awareness  [Marik  99a],  for  the  review 
of  the  used  notation  see  Appendix.  It  provides  the  agent  with  knowledge  structures  and  mechanisms 
of  maintaining  social  knowledge  about  other  collaborating  agents  in  order  to  avoid  expensive 
communication.  Precompiled  social  knowledge  used  for  fast,  efficient  and  accurate  decision  making 
is  administered  in  three  separate  bases: 

-  Cooperator  base  -  maintains  permanent  knowledge  about  collaborating  members  of  the 
community  (e.g.  their  abilities,  addresses,  communication  languages,  etc.). 

-  State  base  -  maintains  nonpermanent  information  about  actual  load  and  agendas  of 
collaborating  agents.  This  base  comprises  two  sections:  Task  Section  -  collecting  information 
about  the  course  of  planning  and  executing  of  the  processed  task  and  Agent  Section  — 
containing  information  about  the  actual  load  of  the  collaborating  agents. 

-  Task  base  -  contains  pre-prepared  plans  how  to  decompose  and  delegate  possible  requests. 
This  base  has  been  also  broken  into  two  sections:  Problem  Section  (PRS)  —  which  is  a  set  of 
task- decomposition  rules  and  Plan  Section  (PLS)  -  containing  a  complete,  close  to  optimal, 
decomposition  plans. 

As  we  will  demonstrate  throughout  this  study  the  tri-base  acquaintance  model  saves  substantial 
portion  of  communication  requirements  of  the  multi-agent  system.  The  communication  efficiency 
improvements  provided  by  this  approach  may  be  seen  as  a  specific  communication  load  shift.  The 
communication  load  is  minimized  in  the  agent's  critical  time  (i.e.:  moment  when  the  agents  are  required 
to  fulfill  a  request)  while  a  new  model  maintenance  activity  appears  in  the  agent's  idle  time.  Each 
request  is  answered  quickly  but  it  brings  substantial  communication  flows  after  answering  the 
request. 

Hereafter  we  will  refer  to  a  contractor  as  an  agent  who  contracts  another  agent  with  a  request.  A 
contractee  is  an  agent  who  was  contracted  by  another  agent  with  respect  to  a  request.  Similarly  a 
subscriber  is  an  agent  who  subscribes  another  agents  for  reporting  on  its  services  and  a  subscribee  is 
an  agent  who  was  subscribed.  Subscribee  keeps  sending  advertises  to  a  subscriber  each  time  its  status 
gets  updated  [Pechoucek  00]. 


Methods  of  communication 

In  order  to  justify  the  proposed  methodology  and  provide  solid  experimental  results,  we  comparethe 
load  of  the  acquaintance  model  type  of  communication  with  simple  broadcasting  mechanism.  We 
will  illustrate  results  of  our  work  on  a  very  typical  communication  stereotype  —  a  request  for 
decomposition.  If  an  agent  is  requested  to  decompose  a  task  it  shall  detect  the  best  possible 
collaborators  (based  on  its  knowledge  of  decomposition)  and  contract  these  with  parts  of  the  original 
request. 

Hereafter  we  will  refer  to  broadcasting  based  task  decomposition  as  a  communication  convention 
consisting  of  three  phases  -  (i)  broadcast  phase  where  a  decomposing  agent  ( 'contractee j  broadcasts  a 
tender  for  cooperation,  (ii)  bidding  phase  where  interested  agents  reply  their  offers  and  (iii)  contract 
phase  when  the  contractee  selects  the  best  possible  contractor  and  contracts  it  with  a  request  for 
collaboration.  We  will  refer  to  acquaintance  model  based  decomposition  as  a  communication  protocol  that 
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involves  two  phases  -  (i)  contract  phase  when  the  contractee  contracts  best  possible  agents  for 
collaboration  (decision  is  based  on  knowledge  stored  in  the  agent’s  acquaintance  model)  and  (ii) 
model  maintenance  phase  when  contracted  agent  advertises  change  of  its  status  (caused  by  the 
contract)  within  the  group  of  its  subscribers,  i.e.  agents  who  subscribed  the  appropriate  agent  for  this 
information.  Developers  in  the  team  used  terminology  based  on  KQML  performatives 
corresponding  to  each  of  the  phases.  The  contract  phase  is  referred  to  as  an  achieve  phase,  the 
broadcast  and  the  bidding  phases  are  jointly  named  as  evaluate  phase  and  the  model  maintenance 
phase  is  called  advertise  phase.  There  is  another  quite  important  communication  phase  in  the  life  of 
the  community,  which  we  call  register  phase.  In  this  phase  agents  get  constructed  and  mutually 
acquainted.  This  process  is  inevitable  for  further  utilization  of  an  acquaintance  model.  Naturally  the 
process  of  mutual  exchange  of  information  among  the  agents  is  expensive  in  terms  of 
communication  and  may  become  a  bottleneck  in  the  case  of  large  communities. 


Broadcast 

Tri-Base 

register 

broadcast 

bid 

contract 

contract 

maintenance 

register 


evaluate 


achieve 

advertise 


Figure  1  —  Models  of  Communication 

In  the  report  we  will  refer  to  a  broadcasting  agent  as  an  agent  who  does  not  maintain  an  acquaintance 
model  and  carries  out  broadcasting  based  task  decomposition  and  to  acquaintance  based  agent  as  an 
agent  who  decomposes  requirements  by  using  social  knowledge  stored  in  its  acquaintance  model  and 
thus  carries  out  acquaintance  model  based  decomposition 

Let  us  consider  an  acquaintance  based  agent  A.  to  be  free  to  decide  about  its  collaborators  if  its 
knowledge  base  (PRS  in  the  TB)  provides  several  alternatives  how  to  decompose  at  least  one 
requirement  and  how  to  delegate  responsibility: 

A  is  free  iff  3Te  p  (A)  (|co(N[,T)|  >  1), 

where  |  M  |  denotes  the  cardinality  of  the  set  M. 

A  degree  of  cooperation  freedom  of  the  community  0,  denoted  as  <p(0),  is  the  number  of  agents  who  are 
free  to  make  their  choice  whom  to  contract  and  whom  to  delegate  with  decomposed  subtasks: 

tp  (0)  —  |{  M.  Ae  0  A  A  is  free}| 

Any  free  agent  either  broadcasts  a  request  and  waits  for  offers  from  possible  candidates  or  uses  some 
piece  of  social  knowledge  to  make  the  rational  decision.  On  the  other  hand,  if  agent's  knowledge 
provides  only  fixed  decomposition  assignments,  the  agent  does  not  have  any  freedom  to  select  its 
collaborators.  It  is  obvious  that  in  the  latter  case  the  communication  complexity  is  substantially 
smaller.  The  degree  of  cooperation  freedom  of  the  community  is  thus  equivalent  to  number  of  agents 
free  to  form  the  team  collaborators  for  a  specific  project. 

However  for  many  purposes  the  introduced  metric  is  not  precise  enough.  For  each  particular  request 
the  community  has  different  degree  of  cooperation  freedom  (as  a  specific  agent  can  choose  between 
two  variants  when  solving  certain  task,  but  for  another  task  there  is  only  one  decomposition 
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possible).  We  say,  that  the  agent  B  is  free  for  the  task  r  iff  B  knows  about  more  than  one 
decompositions  for  r,  i.e. 

agent  B  is  free  for  the  task  r  iff  |co(f3,  r)  |  >  1. 

Let  9;{0)  denote  the  number  of  agents  which  are  free  for  the  task  r.  Then  tp(0)  as  defined  above  is 
an  upper  bound  estimate  of  ^r(0)  for  each  particular  task  r.  A  more  precise  metric  may  be  the  sum 
of  all  degrees  %(&)  per  each  request  r, 

I  ^0), 

ifiS 

or  the  average  degree  of  freedom  per  single  request. 

Complexity  of  the  decision  making  process  is  significantly  influenced  by  “substitutability55  among 
agents.  Thus  another  interesting  measure  corresponds  to  the  maximal  number  of  different  agents, 
which  are  able  to  solve  a  single  task.  In  the  rest  of  the  report  we  will  stick  to  the  first  measure  tp(0), 
refered  to  as  the  degree  of  cooperating  freedom. 


Communities  Tested 

Utilization  of  the  3bA  model  has  been  experimentally  justified  by  means  of  tests  carried  out  in  the 
ProPlanT  multi-agent  system.  As  explained  in  the  first  report,  there  are  three  fundamental  classes  of 
the  system’s  community.  For  the  purpose  of  further  explanation  let  us  distinguish  among 
decomposition  agents  (DA),  where  we  include  ProPlanT  PPA  (production  planning  agents)  and  PMA 
(production  managing  agents)  and  resource  agents  (RA),  where  we  count  PA  (production  agents) 
agents  of  various  types.  While  resource  agents  provide  other  agents  with  some  service  or  commodity, 
the  decomposition  agents  are  responsible  for  optimal  decomposition  of  a  task  into  a  set  of  subtasks 
and  further  delegation  among  collaborating  agents.  This  classification  of  agents  in  terms  of  their 
capability  to  decompose  and  delegate  bears  a  resemblance  to  the  Pleiades  architecture  of 
collaborative  agents  architecture  that  consists  of  task-specific  agents  (TA)  and  information-specific  agents 
(l A)  [Sycara  95]. 

As  we  did  not  have  an  access  to  military-related  test  cases  and  experimental  data,  entire  simulation 
was  carried  out  on  the  community  of  agents  planning  manufacturing  of  compressors  within  a  factory. 
The  task  of  the  community  is  to  come  to  a  general  agreement  on  how  to  allocate  given  pieces  of 
production  when  considering  an  internal  structure  of  the  manufacturing  process. 

We  have  experimented  with  three  different  configurations  of  the  “same55  community,  i.e.  a 
community  with  the  same  functionality  (set  of  treated  tasks)  as  the  original  one.  The  original 
community  consists  of  17  agents  of  a  different  nature,  6  of  which  are  free  (have  a  free  choice  to 
contract  the  other  agents  and  thus  decide  on  optimality).  Moreover,  for  any  free  agent  holds  that  all 
the  tasks  he  treats  have  at  least  2  different  decompositions. 

As  already  noted  the  functionality  of  the  multi-agent  system  (Figure  2  )  has  been  implemented  by 
means  of  three  different  community  configurations.  Each  new  configuration  is  derived  from  the 
original  one  by  adding  (eventually  simplified)  “copies55  of  selected  agents  existing  in  the  original 
community: 

•  community  no.  1  —  The  original  community  consisting  of  6  decomposition  agents 
(management,  quality,  production,  dispatching,  materiel  and  pea)  and  11  RA  (coopl,  coop2,  store, 


6 


assl,  ass2,  worksl,  works2,  tester,  road,  train,  config).  This  is  the  original  community  has  17 
agents1. 


figure  2  —  Testing  Community  no.  1 . 

•  community  no.  2  -  Higher  communication  traffic  has  been  tested  on  this  community.  We 
have  extended  the  community  with  several  other  DA  agents.  As  the  overall  functionality  of 
the  community  shall  not  be  modified,  separate  DA  agent  has  been  constructed  for  each  single 
task,  which  any  of  decomposition  agents  from  the  first  community  accounts  for.  This  is  why 
the  number  of  decomposition  agents  has  risen  up  to  36  (pea  1,  management  9,  quality  5, 
production  9,  dispatching  3,  material  9),  while  all  of  them  remained  free.  The  total  number  of 
agents  for  this  case  is  47  and  the  degree  of  freedom  is  36. 

•  community  no.  3  —  The  community  with  even  higher  communication  traffic  has  been  created 
from  the  community  no.  2  by  separating  the  resource  agents  so  that  there  is  a  single  RA 
accountable  for  a  single  task.  By  doing  so  we  got  78  RA  agents  (coopl  12,  coop2  12,  store  11, 
assl  9,  ass2  12,  worksl  6,  works2  9,  tester  5,  road  2,  train  2,  config  1).  Total  number  of  agents  is 
thus  115  while  the  degree  of  freedom  still  remained  36. 


Experimental  Results 

In  order  to  confirm  the  communication  savings  estimates  we  have  designed  two  different 
experiments.  Firstly  communication  requirements  of  the  tri-base  agent  and  broadcasting  agent  were 
compared  with  respect  to  different  degree  of  freedom  of  a  single  community  —  community  no.  1. 
Within  this  experiment  we  modified  the  original  community  in  order  to  achieve  various 
modifications  with  a  different  degree  of  freedom.  Modifications  of  the  degree  of  freedom  resulted 
from  changes  of  different  agents5  knowledge  stored  in  their  task  bases.  Within  the  second 
experiment  we  measured  communication  savings  in  three  different  communities  of  agents. 


1  Note  that  DA  agents  are  represented  by  boxes  with  gray  fillings  while  RA  are  represented  by  boxes  with  white  fillings. 
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Broadcasting  Agent  vrs.  Tri-base  Agent  with  Different  Degree  of  Freedom 

We  have  carried  out  simple  tests  in  order  to  compare  communication  requirements  for  a  single 
decomposition  request  sent  to  the  community  of  broadcasting  agents  and  tri-base  agents  with 
different  degrees  of  cooperation  freedom.  This  experiment  has  been  carried  out  in  the  simplest 
community  from  above  —  community  no.  1.  The  degree  of  cooperation  freedom  has  been  set  by 
interventions  into  agents’  decomposition  knowledge  stored  in  their  knowledge  bases  by  disabling  or 
adding  some  alternative  decompositions  for  specific  tasks.  We  have  experimented  with  both  the 
marginal  cases  —  no  cooperation  freedom  (community  no.  la)  and  full  cooperation  freedom  of  all 
decomposition  agents  (community  no.  1),  as  well  as  with  the  case  of  only  two  free  agents  (community 
no.  lb).  The  last  community  is  very  similar  to  our  real  life  example  form  production  planning.  For 
results  see  Table  1 . 


community 

cp(0) 

number  of  messages 

m(3bA) 

m(broadcast) 

m(maint) 

la 

0 

30 

30 

123 

lb 

2 

30 

46 

123 

1 

7 

30 

180 

123 

Table  1  —  Test  no.  1  results 


The  first  column  of  the  Table  1  (m(3bA))  shows  number  of  messages  sent  within  the  community 
during  the  achieve  phase.  As  the  degree  of  freedom  affects  communication  only  in  the  evaluate  (in  the 
case  of  broadcasting),  there  is  still  the  same  number  of  messages  measured  for  each  tp(0).  Although 
communication  in  the  maintenance  phase  -  the  third  column  of  the  table  -  does  not  depend  on 
tp(0).  It  is  rather  related  to  the  architecture  of  the  community,  as  will  be  illustrated  in  the  next 
experiment.  Therefore  there  is  the  same  value  in  each  row.  The  second  column  gives  the  total 
number  of  messages  sent  by  the  broadcasting  agent.  The  first  value  is  the  same  as  in  the  tri-base 
agent:  for  ^(©)=0  there  is  no  decision  making  process  about  whom  to  delegate  the  decomposition 
with  and  therefore  there  is  no  evaluate  phase.  The  last  number  illustrates  the  case  where  each  agent 
who  is  contracted  with  a  request  broadcasts  a  call  for  cooperation  within  all  agents,  who 
consequently  reply  with  their  offers  and  the  agent  contracts  the  optimal  one. 

The  higher  is  the  degree  of  cooperation  freedom  of  the  community,  the  more  communication  traffic 
is  required  and  the  acquaintance  model  rises  its  impact  on  the  communication  savings.  In  the 
marginal  case  with  fixed  task  decomposition  and  job  delegation  (tp(0)  =  0),  the  acquaintance  model 
has  no  utilization  while  substantial  communication  needed  for  the  model  maintenance  is  required. 
The  broadcasting  agent  does  not  have  to  carry  out  any  bidding  (evaluate  communication  phase)  and 
directly  contracts  (achieve  communication  phase)  the  single  relevant  agent  (of  which  the  broadcasting 
agent  knows  from  the  communication  structure).  Broadcasting  based  decomposition  consists  in  this 
case  from  the  achieve  stage  communication  only  and  therefore  communication  requirements  for 
either  approaches  shall  be  identical  (m(3bA)  =  m(broadcast)  =  30).  However,  the  tri-base  agent  needs 
to  spend  certain  amount  of  communication  resources  for  maintenance  of  their  models 
(m(maintenance)  =  123).  This  is  why  utilization  of  the  tri-base  models  is  not  very  likely  to  pay  off  in 
this  case.  On  the  other  hand,  in  the  case  of  total  cooperation  freedom  (f(0)  =  7)  in  the  considered 
community  no.  1,  the  broadcasting  agent  would  have  to  exchange  six  times  more  messages 
(m(broadcast)  =  180)  than  the  tri-base  agent  (m(tri-base)  =  30)  in  the  community  critical  time.  The 
total  number  of  messages  sent  in  the  whole  communication  cycle  of  tri-base  agent  is  also  smaller 
(m(tri-base)+m(maintenance)  =  153  <  m(broadcast)  =  180).  In  the  mentioned  example,  reflecting  the 
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real  organizational  structure  in  the  plant  (see  [Pechoucek  00a]),  there  are  only  two  agents  (production, 
material)  making  their  own  choices  in  terms  of  optimal  allocation  of  collaborating  agents  workload. 
An  interesting  observation  is  that  in  this  case  with  rather  low  degree  of  collaboration  freedom  (tp(©) 
=  2)  the  tri-base  agent  saves  already  more  than  one  third  of  communication  requirements  (m(tri-base) 
=  30  <  m(broadcast)  =  46)  in  the  critical  times. 

Broadcasting  Agent  vrs.  Tri-base  Agent  in  Different  Communties 

The  principal  subject  of  the  second  experiment  was  the  community  of  17  agents  with  seven  free 
agents  (tp(0)  =  7)  —  community  no.l.  Communication  savings  were  tested  also  in  other  two 
communities  —  community  no.  2  and  community  no.  3,  whose  architectures  were  based  on 
functionality  of  the  community  no.  1.  Although  with  increasing  number  of  agents  the  degree  of 
freedom  of  the  community  may  increase2,  for  a  specific  request  there  are  still  two  free  agents  within 
the  available  part  of  the  involved  community.  This  is  why  the  degree  of  freedom  was  not  an  issue 
when  experimenting  with  the  different  communities. 

Table  2  summarizes  the  test  results.  The  first  part  of  the  table  provides  detailed  structure  of  each  of 
communities.  Second  part  of  the  table  gives  a  full  amount  of  communication  messages  per 
decomposition  cycle  for  acquaintance  based  decomposition.  Each  row  gives  number  of  messages  in 
an  appropriate  communication  phase  of  one  decomposition  cycle.  In  addition  to  this  we  illustrate 
communication  requirement  in  the  registration  phase.  The  last  part  of  the  table  provides  results  of 
measurements  of  the  broadcasting  based  decomposition  communication  requirements. 


community  no.  1 

community  no.  2 

community  no.  3 

number  of  RA  agents 

11 

11 

78 

number  of  DA  agents 

6 

36 

36 

total  number  of  agents 

17 

47 

115 

acquaintance  based  decomposition  -  number  of  messages 

register 

173 

1871 

4517 

contract 

30 

30 

30 

maintenance 

123 

206 

31 

total  per  request 

153 

236 

61 

broadcasting  based  decomposition  -  number  of  messages 

register 

27 

58 

196 

evaluate 

150 

285 

788 

achieve 

30 

30 

30 

total  per  request 

183 

315 

818 

Table  2  —  Test  no.  2  results 


2  ^((H>)  increases  with  increasing  number  of  agents  in  our  case  because  new  DA  agents  were  constructed  so  that  each  DA 
agent  accounts  for  one  particular  task,  while  still  maintaining  the  same  number  of  decomposition  alternatives  as  in  the 
community  no.  1.  If  a  new  community  was  constructed  so  some  DA  agent  there  would  be  constructed  agents  where  a 
single  agent  would  account  for  one  decomposition  alternatives,  the  decision  making  freedom  would  be  shifted  up  to  the 
agent  who  contracts  the  agent  in  question  and  the  degree  of  freedom  may  eventually  decrease.  This  is  not  however  our  case. 
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As  expected,  experiments  show  that  with  increasing  number  of  agents  in  the  community  the  3bA 
model  provides  more  of  communication  savings.  The  overall  degree  of  freedom  rises  with  increasing 
number  of  agents.  Consequently  this  observation  is  not  in  contradiction  with  results  from  the 
previous  experiments. 

Another  important  observation  regards  sharing  resources.  Sharing  resources  brings  difficulties  to  the 
tri-base  agents.  While  the  community  of  47  agents  needs  206  messages  for  model  maintenance  115 
agents  community  requires  31  maintenance  messages.  The  reason  for  this  is  that  in  the  former 
community  no.  2  there  are  36  DA  agents  contracting  11  RA  agents.  Resource  agents  have  to  be 
therefore  inevitably  shared.  The  latter  community  no.  3  is  organized  in  a  tree  and  this  is  why  no  RA 
agent  may  be  contracted  by  two  different  DAs  and  thus  it  advertises  to  single  agent  only.  However, 
the  organization  of  the  community  does  not  have  any  impact  on  communication  load  of  the 
broadcasting  agent.  The  increased  number  of  RA  agents  will  economize  the  flow  of  advertise 
messages  sent  from  the  level  of  RAs  towards  DA  agents.  As  the  community  is  organized  in  tree-like 
manner  with  the  high  branching  factor  in  the  close-to-leaves  levels  of  the  tree,  it  is  easy  to  back- 
propagate  an  update  within  the  community  (maintenance  —  31)  than  searching  for  an  optimal 
configuration  (evaluate  —  788). 

The  drawback  of  all  the  acquaintance-model-based  approaches  is  the  register  phase.  Unlike 
broadcasting  agent,  the  tri-base  agent  has  to  set  subscribe-advertise  links  with  its  pears  prior  to 
functioning  of  the  community.  This  is  what  is  rather  time  consuming  and  may  become  a  bottleneck 
with  large  communities  (4517  messages  among  115  agents).  Fortunately  this  process  has  to  be  gone 
through  only  once  when  the  community  is  created.  However,  new  ideas  how  to  optimize  this 
problem  are  discussed  later  within  the  report. 


Frequency 

As  already  mentioned  the  communication  savings  offered  by  this  approach  may  be  seen  as  a  specific 
communication  load  shift.  Tri-base  minimizes  communication  load  in  the  agent's  contract  phases 
while  a  new  advertising  activity  appears  in  the  agent's  maintenance  phase.  Each  request  is  answered 
quickly  but  it  brings  substantial  communication  flows  following  the  request  fulfillment.  The  contract 
phase  is  usually  placed  in  community  critical  time  of  operation,  when  agents  are  required  to  answer 
promptly.  The  virtue  is  that  the  maintenance  phase  is  carried  out  in  the  community  idle  times ,  where 
agents  are  not  required  to  provide  any  assistance  to  the  user.  Successful  operation  of  such  a  multi¬ 
agent  system  depends  on  the  community  lifecycle.  In  order  to  utilize  this  acquaintance  model  based 
mechanism  and  to  guarantee  its  communication  savings  for  the  frequency  f  of  requirements  to  plan 
the  following  condition  should  be  met 


where  tc  is  maximum  amount  of  time  spent  in  the  critical  time  planning  and  U  is  maximum  amount  of 
time  needed  for  processing  the  subscription/ advertise  mechanism  in  agents'  idle  time. 

This  observation  suggests  exclusion  of  possible  processing  of  parallel  requests  within  the  community 
(as  minimal  gap  between  two  consecutive  requests  is  required).  If  there  are  two  completely 
independent  requests  coming  at  the  same  time,  quality  of  the  decomposition,  time  of  the  response 
and  communication  requirements  are  unaffected  by  this  irregularity. 
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Figure  3  —  Conflicts  caused  by  shared  resources 


However  sharing  resources  causes  conflicts.  Let  us  assume  that  two  different  requests  will  need  to 
share  resources  of  a  single  agent.  In  the  simplest  possible  case  of  the  previous  two  agents  (A/,  A.?)  try 
to  contract  either  of  their  two  subscribees  (13/,  13?)  for  carrying  out  task  /  (time(/)=3).  Each  of 
subsribees  advertised  its  offer  —  Bi(t)  —  10  and  B?(/)  =  12.  The  agent  H/  makes  a  sound  decision  and 
contracts  agent  13/  with  a  task  /.  Provided  the  agent  H?,  who  did  the  same  decision  as  the  agent  H/, 
contracts  the  agent  13/  prior  to  agent  13/  advertising  a  new  offer  (thus  fading  to  meet  the  above 
mentioned  condition)  H?  will  obtain  a  reply  that  will  be  in  conflict  with  the  social  information  the 
agent  H?  maintains  about  the  agent  13/  in  its  wrapper. 

In  the  current  implementation  of  the  tri-base  agent  within  the  community  fails  to  provide  an  optimal 
answer  due  to  the  conflict  mentioned  above  and  brings  about  a  global  failure  (sorry  KQML 
message).  In  another  philosophy  the  community  will  ignore  the  conflict  and  will  reply  with  an  answer 
that  will  not  be  optimal  (such  as  agent  H?  accepting  collaboration  with  13/  although  the  task  will  be 
completed  in  13  times  unit  where  the  optimal  solution  would  be  provided  by  agent  13?  in  12  time 
units).  The  best  possible  approach  suggests  refusing  such  a  contract,  updating  the  tri-base  model 
according  to  conflict  and  carry  out  local  re-planning.  It  is  easy  to  understand  that  this  approach 
brings  an  optimal  answer  but  at  the  cost  of  some  extra  communication.  This  is  what  we  wanted  to 
emphasize  in  this  paragraph. 


Open  Issues 

When  applying  the  tri-base  acquaintance  model  in  critical  domains  one  would  need  to  economize 
several  aspects  of  the  knowledge  maintenance  mechanisms. 

Register-Phase 

Firstly  (and  maybe  most  importantly)  the  communication  load  in  the  register-phase  of  the 
community  shall  be  brought  to  minimum.  We  have  carried  out  separate  research  in  the  areas  of 
efficient  community  configuration.  The  currently  investigated  ideas  are  based  on  replacing  the 
presently  used  mechanisms  of  configuring  communication  links.  These  mechanisms  are  based  on  an 
intense  broadcast  within  the  entire  community,  where  each  decomposition  agent  is  fishing  for 
possible  future  collaborators. 

An  elegant  solution  is  to  utilize  a  facilitator,  who  the  agents  have  to  register  with  if  they  desire  to 
participate  in  the  community.  Apart  from  their  symbolic  name,  IP  address  and  port  number,  the 
agents  will  register  also  their  capabilities  and  services.  Such  a  community  component  will  resemble 
functionality  of  a  FIPA  [fipa98]  normative  directory  facilitator  (DF)  who  provides  “ydl°w  pages55 
services  to  other  agents.  Even  though  this  is  a  standard  way,  we  wanted  to  test  our  approach  in  the 
environment  with  minimal  centrality  and  maximum  autonomous  rationality  of  participating  agents. 
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Advertise  Messages 

Another  open  issue  regards  optimization  of  the  advertise  messages  sent  after  an  update  of  the 
community.  Currently  we  send  a  lot  of  unneeded  information  when  a  single  little  change  is  advertised 
to  subscribers.  Firsdy  we  have  to  decide  what  is  a  relevant  change.  Combination  of  (i)  how  old  is  the 
latest  advertise,  (ii)  how  relevant  is  the  information  to  be  advertised  and  (iii)  how  substantial  is  the 
advertised  change  shall  be  considered  when  triggering  knowledge  maintenance  process  through 
advertise  messages.  We  came  across  this  problem  when  implementing  real  time  reasoning  into  our 
agents.  Each  tick  of  a  timer  triggers  a  massive  re- computation  of  all  advertise  messages  and  causes 
communication  overload. 

Cooperation  Neighborhood 

In  order  to  optimize  the  communication  flow  we  have  to  maintain  the  agents5  cooperation 
neighborhood  We  have  shown  how  the  agents  can  join  someone's  cooperation  neighborhood. 

However  neither  means  for  subscribers  to  leave  the  cooperation  neighborhood,  nor  for  subscribee  to 
discontinue  advertising  to  a  subscriber,  have  been  until  now  implemented  and  experimented  with. 
For  comments  on  this  issue  see  the  next  section. 

Problem  Solving  Neighborhood 

Another  optimization  challenge  of  the  community  of  planning  agents  is  based  on  careful 
maintenance  of  the  agent's  problem  solving  neighborhood  7V(A).  An  agent  may  be  constructed  with 
predefined  responsibility  to  account  for  certain  task,  which  is  rarely  requested.  It  hardly  pays  off  to 
maintain  such  a  decomposition  plan  pre-prepared  in  the  agent's  task  base.  It  is  rather  uneasy  to 
decide  which  task  is  important  and  which  shall  not  be  kept  within  the  agent's  problem  solving 
neighborhood. 
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Machine  Learning  in  3bA  Model  Optimization 


Though  the  experimental  results  showed  substantial  savings  of  the  overall  communication  traffic 
(provided  given  assumptions),  full  exploitation  of  this  methodology  is  based  on  proper  maintenance 
of  it’s  the  3bA  content  but  also  with  dynamics  of  its  structure.  The  previous  section  indicates  that  the 
agent’s  acquaintance  model  shall  not  be  only  a  static  container  of  data  maintained  primarily  by 
collaborating  peer  agents.  Agent  itself  shall  use  its  experience  in  order  to  affect  many  aspects  of  the 
knowledge  maintenance  process  dynamics. 

Knowledge  acquired  from  the  historical  behaviour  of  the  system  or  from  a  part  of  the  system 
contributes  to  overall  systems  efficiency  improvements.  In  principle,  we  distinguish  between 

—  single  agent  learning,  where  one  individual  agent  analyses  accessible  data  (most  likely 
record  of  agent's  historical  performance)  in  order  to  revise  knowledge  stored  in  its  tri¬ 
base 

—  meta-agent  learning,  where  the  overall  community  behaviour  is  analyzed  and  efficiency 
improvements  are  sent  to  individual  agents  who  update  their  social  models. 

For  the  complete  list  of  efficiency  improvements  caused  by  possible  tri-base  revisions  see 
[Stepankova  98] 


Single  Agent  Learning 

Cooperation  Neighborhood  Optimization 

As  defined  [Pechoucek  00],  the  agents'  cooperation  neighborhood  £ t(M)  is  a  set  of  agent's  A 
collaborators  at  the  time  instant  t.  More  precisely  we  talk  about  agents,  the  agent  A  subscribed  for 
reporting  on  their  actual  status.  These  agents  are  listed  in  the  agent  section  (AS)  of  the  agent's  state  base 

(SB). 

In  the  previous  section  we  said  that  although  members  of  the  ProPlanT  community  can  join 
someone’s  cooperation  neighborhood,  there  are  no  means  for  subscribers  to  restrict  the  cooperation 
neighborhood,  or  for  subscribee  to  discontinue  advertising  to  a  subscriber.  Introduction  of  a  new 
performative  —  unsubscribe  —  will  allow  subscribers  to  restrict  their  cooperation  neighborhoods  as 
well  as  the  performative  subscribe  expands  it.  Subscribees  do  not  necessarily  need  to  be  benevolent. 
Subscribed  agents  may  easily  discontinue  advertising  their  status  in  spite  of  the  fact  they  are 
subscribed.  They  have  to  have  only  a  good  reason  for  doing  so. 

We  have  shown  that  implementing  technical  means  for  maintenance  of  the  agents'  cooperation 
neighborhood  is  not  a  big  research  challenge.  What  is  much  more  interesting,  is  detection  of  when 
and  how  the  cooperation  neighborhood  would  be  revised.  Let  us  call  a  subscriber-subscribee  link  to 
be  unexploited  if  and  only  if  subscriber  did  not  contract  the  subscribee  for  certain  threshold  period  of 
time  (told)-  Restriction  of  the  cooperation  neighborhood  may  be  thus  driven  two-fold: 

—  either  the  subscriber  agent  may  analyze  record  of  its  communication  history  and  easily 
detect  unexploited  links  (with  respect  to  t0id)  and  unsubscribe  appropriate  subscribees, 

—  or  the  sunscribee  agent  will  analyze  its  record  of  past  communication  and  stop 
advertising  to  agents  who  did  not  contract  it  for  longer  than  t0id  (the  subscriber  shall  be 
informed  of  this). 
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If  the  subscriber  needs  to  contract  unsubscribed  subscribee,  it  subscribes  it  first  and  then  does  usual 
decision  making.  The  communication  requirements  of  this  process  will  not  be  worse  than  local 
broadcasting  communication.  This  is  why,  careful  specification  of  the  threshold  value  t0id  will  affect 
the  overall  system  efficiency. 

It  is  very  often  the  case  that  a  single  agent  advertises  lot  of  unneeded  information  though  just 
information  about  one  particular  resource  is  looked-for.  If  we  assume  that  a  subscriber 
subscribes/unsubscribes  not  only  an  agent  but  an  agent  for  a  particular  task,  the  identical  mechanism 
may  be  used  with  advantage  for  optimization  of  subscribed  information  the  agents  advertise. 

In  this  way  the  community  will  start  with  the  biggest  possible  cooperation  neighborhood  and  will 
restrict  it  throughout  the  life  of  the  community.  An  alternative  way  is  to  start  with  all  links 
unsubscribed  and  subscribe  a  new  link  when  a  requirement  to  contract  arises.  Experiments  (which 
were  not  part  of  this  study)  may  disclose  which  of  these  two  approaches  provides  better  overall 
system  efficiency  and  indicate  what  is  the  relationship  between  the  threshold  value  t0id  and  amount  of 
communication  within  the  system,  a  measure  of  the  promptness  of  response  and  system's  efficiency 
as  such. 


Amount  of  advertised  messages  can  be  also  pruned  with  respect  to  how  relevant  is  the  reported 
update.  Let  us  assume  that  the  state  change  of  the  agents  is  relevant  if  either  its  load  changes  so  that 


Load1  (A)  -  l_oad2  (A) 
Load  i(A) 


>t 


rel 


or  there  is  at  least  one  (T,  Cost (T))  E  Cap(B)  for  which  holds 

Cosy  (AT)  -  Cosy  (A) 

Cosy  (A) 

In  other  words  we  say  that  any  advertise  update  is  relevant  if  a  change  of  at  least  on  a  piece  of 
advertised  information  is  bigger  than  4/-  Though  it  does  not  have  anything  much  to  do  with 
cooperation  neighborhood,  in  the  sense  as  defined  within  the  project,  avoiding  irrelevant  update 
report  may  save  substantial  part  of  communication. 

Another  way  how  we  can  reduce  the  amount  of  communicated  messages  in  the  knowledge 
maintenance  process  is  based  on  periodical  revisions  carried  out  by  the  community  [Cao 
97]  [Stepankova  98].  If  the  frequency  of  requests  is  much  smaller  than  agents'  states  updates,  there  is  a 
large  number  of  advertise  messages  that  no  one  actually  needed.  So  instead  of  the  state  update  back 
propagation  in  the  moment  of  the  slightest,  unimportant  change  of  a  single  EA  agent  within 
community,  agents  advertise  in  certain  periodical  moments.  We  did  not  consider  this  way  as  very 
promising.  In  order  to  save  communication,  periodical  revisions  would  have  to  be  comparatively 
rare.  This  worsens  average  precision  of  the  agents'  social  model  (imprecise  social  model  causes 
another  communication  requirements  in  the  moment  of  request).  Increasing  frequency  of  periodical 
revisions  improves  this  precision  but  will  increase  communication  requirements  that  will  be  close  to 
the  classical  subscribe-advertise  mechanism.  Precise  comparison  would  have  to  be  grounded  in 
experiments. 


Problem  Solving  Neighborhood  Optimization 

While  in  the  previous  paragraph  we  discussed  optimization  of  subscription  links  and  corresponding 
communication  flows,  here  we  will  briefly  comment  optimization  of  problem  solving  resources  of  an 
individual  agent.  The  subject  of  our  discussion  will  be  the  amount  of  plans  stored  in  the  plan  section 
(PIS)  of  the  agent's  task  base  (TB)  and  the  question  how  often  this  structure  has  to  be  revised. 

According  to  [Pechoucek  00b]  each  change  of  the  agents  state  base  (SB)  will  inevitably  trigger  a 
revision  of  the  PIS.  A  change  in  a  load  of  a  subscribed  agent  will  affect  all  plans  in  PIS  that  rely  upon 
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the  subscribed  agent.  These  plans  shall  be  revised  and  the  entire  structure  reordered.  With  limited 
agent's  cooperation  neighborhood  we  reduce  the  number  of  events  that  cause  PIS  revision. 

Computational  complexity  of  PIS  maintenance  process  depends  on  the  structure  of  the  domain 
knowledge  and  architecture  of  the  system.  In  our  experimental  domain  we  had  always  only  several 
records  (say  tens)  in  PIS  and  almost  each  of  them  has  been  implemented  by  different  agents. 
Therefore  any  PIS  revision  was  fast.  However  in  many  cases  the  state  space  modeled  by  the  multi¬ 
agent  system  may  be  complicated  and  exhaustive.  Some  agents  may  administer  substantial  number  of 
plans  in  their  PIS  and  consequently  the  plan  revision  and  PIS  reordering  within  these  agents  may 
become  a  bottleneck  of  the  community  operation. 

This  problem  can  be  addressed  either  on  the 

—  meta-agent  level,  where  meta-agent  learning  is  used  for  bottleneck  detection  which 
results  in  cloning  an  identical  agent  that  helps  to  process  the  request  (we  will  discuss  this 
approach  later  in  the  study) 

—  single  agent  level,  where  we  want  an  agent  itself  to  identify  which  plans  are  obsolete  and 
unexploited  and  retract  these  from  PIS. 

As  in  the  case  of  cooperation  neighborhood  optimization,  single  agent  can  parse  its  historical  record 
of  PIS  utilization  and  retract  unexploited  plans  (with  respect  to  some  4®)-  Similarly  reordering  of  the 
PIS  is  not  required  if  each  of  the  revised  plans  (or  its  part)  did  not  change  its  cost  more  than  4/  in 
percent. 

The  nature  of  the  problem  indicates  that  for  very  complex  problems,  where  some  optimization  of  the 
problem  solving  neighborhood  is  inevitable,  it  is  better  to  start  with  minimal  neighborhood  and  build 
it  up  with  experience  rather  than  pruning  the  maximal  neighborhood.  In  the  latter  case  it  may  happen 
that  agents  will  be  so  heavily  overloaded  from  the  very  start  that  they  will  not  make  it  up  to  some 
optimal  problem  solving  neighborhood.  This  assertion  is  also  subject  of  experimental  validation. 

Sub-task  Assignment  Optimization 

So  far  we  have  been  optimizing  the  overall  communication  load  of  the  community.  The  other  aspect 
that  may  be  a  subject  of  improvement  is  the  quality  of  solution  the  multi-agent  system  finds.  Let  us 
discuss  the  planning  system  (ProPlanT  is  an  instance).  A  planning  system  produces  plans.  Although 
each  agent  optimizes  its  sub-task  decomposition,  this  does  not  mean  that  the  system  will  operate 
optimally  for  a  sequence  of  requests. 

Example: 


Figure  4  —  Sub-task  Assignment  Optimisation 

There  are  three  agents,  one  DAs  and  two  EA.  The  DA  is  able  to  decompose  tasks  x  (x  = 
(a  <  b))  and  y  (y  =  (c)).  RAi  can  do  a  in  7  time  units  and  b  in  2  and  RA2  can  perform  b  in  3 
and  c  in  5.  If  DA  is  required  to  plan  x  and  y  simultaneously  it  will  plan  (under  assumption  of 
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local  optimality)  RAi:  C(o-2),  a(2-9)  and  RA2:  b(9-i2),  although  the  globally  optimal  would  be  RAi: 
a(o-7),  and  RA2:  C(o-5),  bp-io) 

As  we  were  analyzing  past  performance  of  the  system  above,  we  want  the  system  to  be  able  to 
predict  future  request  in  order  to  avoid  this  local  optima.  When  assigning  the  sub  tasks  for  a  given 
request,  it  uses  the  knowledge  about  the  next  request,  to  do  this  assignment  in  a  way,  that  the 
resulting  plan  for  the  current  and  for  the  next  request  is  optimal. 

The  first  learning  issue  is  to  predict  future  events.  But  the  problem  is  that  even  if  the  future  requests 
are  known,  the  algorithm  to  find  the  optimal  assignment  is  very  complicated.  The  second  learning 
goal  is  to  find  shortcuts  for  this  complicated  algorithm.  This  means  to  find  simple  rules  that  lead 
mostly  to  the  same  (optimal)  result,  but  are  much  more  efficient.  The  third  learning  task,  which  arises 
in  this  setting,  is  to  learn  when  to  use  the  simple  original  algorithm  for  sub- task  assignment  and  when 
to  use  the  sophisticated  algorithm.  Clearly,  if  the  plans  generated  by  the  simple  algorithm  do  not 
contain  any  sub-optimal  structures,  the  more  complicated  algorithm  could  make  them  only  worse. 

All  learning  tasks  optimize  the  quality  of  the  resulting  plans.  The  respond  time  could  on  the  other 
hand  increase,  because  of  the  use  of  more  complicated  algorithms  in  the  DA.  Learning  is  mostly 
performed  in  a  distributed  way  within  the  DA  (even  though  it  would  be  possible,  that  the  MA  has  to 
provide  feedback  and  information  to  them).  The  DA  can  apply  their  learned  knowledge  on  their 
own.  As  this  directly  contradicts  our  effort  to  minimize  overall  problem  solving  complexity  of  the 
multi- agent  system  as  whole  we  did  not  pursue  any  implementation  of  algorithms  addressing  tasks  in 
this  paragraph. 

Number  of  Unachieve  Requests  Reduction 

Un-achieve  requests  appear  in  a  multi-agent  system,  if  a  DA  requests  sub-tasks  from  different  agents, 
and  at  least  one  of  these  agents  replies  with  a  sorry  message.  In  this  case  the  agents,  which  already 
have  fixed  the  plans  for  their  tasks  have  to  undo  these  plans,  because  the  whole  plan  cannot  be 
achieved.  Naturally  un-achieves  are  not  desired,  not  only  because  they  cause  additional  computation, 
but  also  because  it  can  be  quite  complicated  to  undo  a  plan,  which  is  already  fixed. 

The  possibility  of  situations  in  which  un-achieve  is  needed,  arises  from  the  fact,  that  the  up-date  of 
the  knowledge  bases  takes  some  time.  In  the  last  example  in  the  paragraph  'Frequency'  we  commented 
on  a  case  where  two  DAs  are  trying  to  send  a  request  to  a  BA  simultaneously,  both  believing  that  the 
KA  is  able  to  achieve  the  given  sub  task  in  time  as  advertised.  But  the  KA  can  achieve  this  task  only 
once,  so  that  the  request,  which  reaches  the  KA  first,  is  answered  positively,  the  other  one  negatively. 
In  order  to  keep  consistent  with  the  rest  of  plan  that  relied  upon  the  failed  task,  already  contracted 
subtask  has  to  be  replanned.  A  task  is  replanned  so  that  it  is  firstly  canceled  (by  means  of  an 
unachieved  requests)  and  than  it  is  planned  again  (by  means  of  an  achieve  requests) 

The  idea  is  to  reduce  the  number  of  un-achieve  request  by  learning  which  tasks  or  agents  are  very 
likely  to  cause  them  and  to  use  this  information  to  wait  for  the  answer  of  these  agents,  before 
sending  requests  to  other  agents.  On  one  hand,  this  leads  to  an  increase  of  the  respond-time,  because 
the  system  is  not  used  optimally.  On  the  other  hand  this  could  reduce  the  respond-time  and  the 
number  of  messages,  by  reducing  the  number  of  un-achieve  requests.  So  this  kind  of  learning  makes 
only  sense  in  settings,  in  which  un-achieve  requests  occur  often.  The  learning  is  performed  in  the 
distributed  way  again. 


Meta-Agent  Learning 

There  are  several  patterns  of  the  inter-agent  communication  and  causalities  among  agents  mutual 
interaction  that  are  rather  hard  to  detect  at  the  level  of  single  agent  learning.  Though  each  agent  will 
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carry  out  an  optimal  decision,  it  may  happen  that  the  problem  solving  process  will  be  inefficient  form 
the  global  perspective  of  the  entire  community. 

Bottleneck  Detection 

We  have  experimented  with  bottleneck  detection.  Our  meta-agent  was  made  to  analyze  the  past  log 
of  communication  in  order  to  detect  a  botdeneck.  If  there  is  a  bottleneck  in  the  system  it  means  that 
that  there  is  an  imbalance  in  the  use  of  the  underlying  resources,  in  opposite  to  the  term  overload  of 
the  system,  which  stands  for  insufficiency  of  the  whole  system  to  deal  with  incoming  requests. 

Example: 

Having  a  simple  community  of  four  DA  agents  and  one  EA  agent  we  will  show  very  naive 
bottleneck  that  cannot  be  detected  on  the  single  agent  level.  Let  us  assume  that  DAi  can 
choose  between  DA2  and  DA3,  where  DA2  advertises  to  be  less  overloaded  than  DA3.  While 
DA3  directly  contracts  EA  agent,  DA2  contracts  DA4  who  contracts  EA.  Let  DA4  be  a 
bottleneck.  In  this  community  DA4  will  get  heavily  overloaded  as  DAi  who  optimizes  the 
decomposition  does  not  have  the  knowledge  of  DA4  status. 


bottleneck 


Figure  5  —  Sub-task  Assignment  Optimisation 


In  principle  we  distinguish  between  two  types  of  bottlenecks.  Under  a  communication  bottleneck  we 
will  understand  a  bottleneck  caused  by  communication  imbalance  within  the  community.  Such  a 
bottleneck  may  be  caused  by  an  agent  with  low  computational  power  or  more  likely  by  slow 
communication  links.  On  the  other  hand  operational  bottleneck  is  caused  by  imbalance  in  specialized 
agents'  operational  load.  In  the  case  of  planning  multi- agent  system  an  agent  with  plan  that  causes  an 
overall  agents  delay  will  be  recognized  as  an  operational  bottleneck.  When  considering  our  example 
the  3bA  model  will  preventing  operational  bottlenecks.  If  the  bottleneck  agent  (DA4)  provides  only 
a  very  slow  plan,  it  advertises  this  information  DA2  who  incorporates  this  information  into  its 
advertise  to  DAi.  The  DA4  will  therefore  prefer  the  plan  provided  by  DA2  and  will  thus  avoid  the 
bottleneck  agent  DA4.  In  the  following  we  will  discuss  communication  bottlenecks. 

Detecting  and  possible  prediction  of  botdenecks  will  contribute  to  the  overall  efficiency 
improvements  of  the  multi-agent  system  operation.  Firstly  agents  who  do  not  have  knowledge  of 
existence  of  the  bottleneck  will  replace  its  locally  optimal  decision  making  with  a  globally  optimal 
decision  making  provided  they  acquire  information  about  the  bottleneck  from  the  meta-agent.  In  the 
context  of  the  previous  example  DAi  would  prefer  DA3  as  it  is  aware  of  DA2  participating  on  a 
bottleneck  route.  Secondly  (and  maybe  more  importandy)  the  meta-agent  will  have  the  capacity  to 
suggest  construction  of  the  stand-in  agent,  an  agent  with  same  functionality  and  communication  links 
as  the  bottleneck  agent.  Stand-in  agent  will  take  over  some  of  the  critical  load. 

When  analyzing  the  operation  of  the  bottleneck,  the  meta-agent  will  have  to  transform  the  log  of 
inter-agent  communication  into  a  model  of  agent's  operational  plans.  For  this  parsing  the  achieve 
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message  content  is  sufficient,  from  which  the  agents'  load  will  be  easily  computed.  Attributes  of 
training  examples  will  be  in  this  case  loads  of  the  community  members.  In  the  case  of  identifying  a 
communication  bottleneck  things  will  get  a  bit  more  complicated.  Agents  load  will  be  worked  out 
from  the  number  of  messages  received  in  a  certain  time  window.  For  this  we  have  to  store  specific 
receive/ sent  times  in  the  log  of  community  messages. 
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Conclusions 


Multi-agent  systems  seems  to  be  an  adequate  vehicle  to  handle  information  processing  in  complex 
technical  systems,  especially  in  the  case  these  systems  are  geographically  distributed. 

The  vast  volume  of  the  inter-agent  communication  traffic,  i.e.  the  number  of  messages  passed  among 
the  agents,  is  often  considered  as  a  weakness  of  multi-agent  solutions.  Assuring  security  in  the 
systems  with  intensive  message  traffic  becomes  to  be  a  hard-core  problem.  One  of  the  opportunities 
offered  by  the  approach  proposed  within  the  frame  of  this  project  is  to  significantly  reduce  the  number 
of  messages  to  be  necessarily  communicated.  The  tri-base  acquaintance  model  of  social  knowledge 
located  in  the  wrappers  of  the  individual  agents  is  used  for  this  purpose.  Both  the  tri-base  model  and 
the  knowledge  maintenance  strategy  (based  on  the  subscribe-advertise  paradigm)  do  enable  the  shifting  of 
the  substantial  part  of  the  traffic  from  the  critical  times  to  idle  time  slots  of  the  system. 

Moreover,  the  number  of  messages  communicated  in  the  idle  time  doesn’t  influence  the  system 
performance.  That  means  that  the  idle-time  messages  can  be  used  for  security  improvements 
(exchange  of  security  confirmations,  sending  of  deeply  coded  messages,  consistency  checking  based 
on  information  redundancy  etc.).  Thus,  the  idle  time  message  exchange  can  be  used  for  detection  of 
intruders  or  for  increasing  the  global  system  security  in  general. 

Machine  learning  techniques  provide  substantial  enhancement  of  the  tri-base  model,  which  could 
help  to  increase  the  overall  adaptivity  and  flexibility  of  the  global  system  in  conditions  of  slightly 
changing  environment.  We  have  analyzed  the  role  of  machine  learning  algorithms  on 

—  a  single  agent  level,  where  characteristics  of  a  single  agent  can  be  improved  by  various 
self-learning  procedures  in  order  to  optimize  agent’s  cooperation  neighborhood  and  its 
problem  solving  scope  and  improve  efficiency  of  the  knowledge  maintenance 
mechanism, 

—  a  m  eta- 1  eve  I,  where  the  results  of  monitoring  of  the  communication  traffic  on  the  level 
of  the  meta-agents  are  explored  in  order  to  improve  overall  systems  efficiency  by  e.g. 
bottleneck  detection. 

A  new  idea  presented  in  this  report  considers  an  introduction  of  the  so  called  stand-in-agent  which 
represents  a  functional  replica  (a  clone)  of  an  overloaded  agent  to  help  to  solve  the  operational 
bottleneck.  It  looks  like  the  technology  of  the  stand-in-agents  should  be  studied  in  more  depth,  as  it 
can  be  used  e.g.  for  estimating  the  behavior  of  temporarily  lost/hidden  agents  (this  problem  is  typical 
for  the  coalition  formation  domain)  and  to  keep  the  overall  system  integrity  (required  for  the  system 
security  purposes)  more  efficiendy. 
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Appendix  1  —  Tri-base  Acquaintance  Model 


Each  of  the  tri-base  agents  is  equipped  with  a  specific  knowledge  of  behavior  of  the  collaborating 
agents  encoded  in  the  tri-base  acquaintance  model  [Marik  98]  in  order  to  provide  an  optimal  task 
decomposition.  Prior  to  formalising  the  model  let  us  introduce  several  primitives  we  will  use 
throughout  the  course  of  explanation.  Let  ©  be  a  set  of  all  agents  within  the  community  and  S  a  set 
of  all  tasks  the  community  members  are  able  to  decompose.  For  eachM  E  ©let 

OC (A)  c:  ©be  an  agent's  total  neighbourhood, ,  a  set  of  agents  an  agent  A  is  aware  of, 

P(/4)  cS  be  the  set  of  all  tasks  the  agent  A  is  able  to  decompose, 

y(T),  contains  all  possible  plans  for  decomposing  the  task  Te  S.  Plan  for  the  task  T  is  in  the 
form  (T,  S,  tf*,  where  S  is  a  set  of  subtasks  which  ensure  completion  of  the  task  T  provided 
that  their  processing  meets  precedence  constraints  0  and  applicability  constraints  C. 

CO (A,T)  C  y(7)  contains  those  plans  for  the  task  T  an  agent  A  knows  about  (if  T  £  P(M)  then 

(0(A,T)  =  0). 

The  following  sets  provide  time  dependent  information.  Let 

&(A)  c  OC  (A)  be  the  agent's  current  cooperation  neighbourhood ,  a  set  of  agent's  A  collaborators  at 
the  time  instant  /, 

V-(A)  C  (3(M)  contain  the  tasks  being  solved  by  the  agent  A  in  a  time  instance  /  and  the  set 

7V(A)  c:  P(M)  be  a  collection  of  tasks  an  agent  A  is  supposed  to  have  pre-prepared  in  advanceO 
in  time  instance  t 

Within  the  tri-base  model  each  agent  maintains  three  knowledge  bases  where  all  the  relevant 
information  about  the  rest  of  the  community  is  stored.  We  distinguish  among: 

CO-OPERATOR  BASE  (CB)  —  maintains  permanent  information  on  co-operating  agents  (i.e.:  their  address, 
communication  language,  and  their  predefined  responsibility).  This  type  of  knowledge  is  expected 
not  to  be  changed  very  often.  CB  (A)  is  then  defined  as 

CB  (A)  =  {(23,  Addr(f3),  Lang(f3),  P(B))}b^U(A)  where 

Ad  dr  (23)  specifies  agent’s  the  address,  Lang  (23)  language  it  communicates,  as  already  mentioned  P(23)  is 
a  set  of  tasks  the  agent  accounts  for  and  the  set  OC  (A)  denotes  members  of  the  agent's  A  scope  of  the 
community. 

TASK  BASE  (TB)  —  stores  in  its  problem  section  (PRS)  general  problem  solving  knowledge  —  (i)  information 
on  possible  decompositions  of  the  tasks  to  be  solved  by  the  agent  and  (ii)  in  its  plan  section  (PLS)  it 
maintains  the  actual  and  most  up-to-date  plans  on  how  to  carry  out  those  tasks,  which  are  the  most 
frequently  delegated  to  the  agent  -  the  owner  of  the  task  base,  those  denoted  as  TlpA).  Formal 
definition  of  the  TB  (A)  is  then 


TB  (A)  =  <PRS(M),  PLS  (A)),  where 
PRS  (A)  U  C 0(7>1)  and 

Tefi(A) 
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PLS^)  {(T,  ({(s,  B)}SE s,  ^  ^  T rust(T)» }te u\a^ 

where  for  any  (T,  ({(j,  B)}se  s,  ^  Trust(T)))  E  PLS'(A)  where  exist  ^/,  such  that  following 
constraints  are  met  (T,  S,  rf},  £?/)  E  PRS(/4),  B  E  ^(A),  s  E  (3(B)  and  as  is  a  specialisation  of 
reflecting  the  considered  allocation  of  the  asks  s  E  3)  ^is  refinement  of  rfi  and  both  ^and  ^are 
valid. 

STATE  BASE  (SB)  —stores  in  its  agent  section  (as)  all  information  on  current  load  of  co-operating  agents. 
This  part  of  the  state  base  is  updated  frequently  and  informs  the  agent  who  is  busy  and  who  is 
available  for  collaboration.  In  the  task  section  (ts)  there  is  stored  information  on  status  of  tasks  the 
agent  is  currently  solving.  Formal  description  of  the  SB(*4)  of  agent  A  is  thus 

SB  (A)  =  <ASy4),  TS  (A)),  where 

AS  (A)  =  {(B,  Cap  (B),  l_oad(B),  Trust  (B))}bee\a)  and 

provided  that  agent's  B  capability  has  the  form  of  Cap(B)  =  {(T,  Cost (T))}  te  |3(B),  overall  agent  load  is 
Load(B),  and  trust  in  this  information  in  Trust(B). 

TS(^T)  contains  relevant  information  on  all  the  tasks  agent  A.  agreed  to  supervise  recently.  This  set  is 
denoted  by  Formally 


TS  (A)  *f  {<T,  Dec(T),  State(T),  Trust(7))}TexV)> 

where  decomposition  Dec (T)  is  taken  from  the  PLSt/(_ A)  at  the  moment  of  contract  (time  A).  State  (T) 
partitions  sub  tasks  from  Dec  (T)  into  three  parts:  sub  tasks  finished,  actually  processed,  and  the  rest. 
The  record  is  complemented  with  the  trust  value  Trust (T)  denoting  trust  in  the  plan  of  the  task  T. 

The  agent  is  supposed  to  select  an  optimal  plan  from  the  PLS t(A),  where  an  appropriate  amount  of 
plans  prepared  in  advance  is  stored.  By  this  it  does  not  need  to  contract  peer  agents  in  order  to  find 
out  the  most  appropriate  (optimal)  offers  for  further  problem  delegation.  Knowledge  stored  in  the  PIS 
will  help  the  agent  to  decide  by  itself.  It  is  obvious  that  limiting  the  communication  among  agents 
will  in  its  own  way  decrease  the  computational  complexity  of  the  entire  problem.  The  price  we  have 
to  pay  for  this,  is  a  communication  increase  among  agents  when  updating  the  SB. 

The  model  maintenance  algorithms  are  based  on  a  simple  subscribe/advertise  mechanism.  After 
parsing  the  PrS  knowledge,  each  agent  identifies  possible  collaborators  and  subscribes  these  for 
reporting  on  their  statuses.  The  subscribed  agent  advertises  its  load,  capabilities  and  task  completion 
times  and  costs  estimates  either  periodically  or  when  either  of  these  changes.  This  mechanism 


Figure  6  —  Tri-base  Model  Planning 
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facilitates  the  agent  to  make  the  best  decision  with  no  further  communication. 

The  communication  savings  of  this  approach  may  be  seen  as  a  specific  communication  load  shift. 
The  communication  load  is  minimised  in  the  agent's  critical  time  (i.e.:  moment  when  the  agents  are 
required  to  fulfil,  through  delegation,  a  request)  while  a  new  advertising  activity  appears  in  the  agent's 
idle  time.  Moreover  each  request  is  answered  quickly  but  it  brings  substantial  communication  flows 
following  the  request  fulfilment.  The  truth  is  that  successful  operation  of  such  a  multi- agent  system 
depends  on  the  community  lifecycle.  In  order  to  utilise  this  acquaintance  model  based  mechanism 
and  to  guarantee  its  communication  savings  for  the  frequency  f  of  requirements  to  plan  the  following 
condition  should  be  met 


1/f  >  tc  +  ti, 

where  tc  is  maximum  amount  of  time  spent  in  the  critical  time  planning  and  ti  is  maximum  amount  of 
time  needed  for  processing  the  subscription/ advertise  mechanism  in  agents'  idle  time. 

There  are  two  issues  to  be  addressed  here:  (i)  how  many  peer  agents  to  subscribe  and  (ii)  how  many 
plans  to  keep  pre-prepared.  Cooperation  neighbourhood  &(A)  denotes  a  collection  of  such  agents  B  who 
belong  to  agent's  A  scope  of  collaboration.  All  agents  B  E  S/M)  are  subscribed  by  the  agent  A. 
Maximum  neighbourhood  &(A)  is  specified  when  the  agent  parses  its  problem  solving  knowledge¬ 
base  (PRS)  and  detects  who  will  be  needed  for  further  collaboration.  &(A)  is  fixed  here  for  the  entire 
course  of  agent's  decision  making.  In  this  way,  the  agent  is  collecting  lots  of  redundant  data,  which 
slows  the  community  down  substantially.  The  possible  role  of  the  meta-agent  can  be  in  analysing 
inter- agent  communication  and  optimising  the  S^A)  neighbourhood. 

On  the  other  hand,  711(A)  neighbourhood,  agent's  A  scope  of  reasoning,  specifies  how  many  of  plans 
from  PRS  will  be  kept  instantiated  and  on-line  evaluated  in  PLS  of  the  TB.  We  distinguish  among  two 
marginal  cases.  If  711(A)  =  0,  there  is  no  plan  pre-prepared  and  planning  in  the  critical  time  requires 
substantially  more  of  computational  time  for  constructing  the  PLS  plans.  If  7V(A)  is  maximal,  there  is 
no  time  needed  for  constructing  the  PLS  plans,  but  each  minor  change  within  community  results  in 
massive  re- computation  and  re-evaluation  of  PLS  plans.  Designers  of  the  system  rely  on  meta-agent 
machine  learning  capabilities  in  setting  711(A)  agent's  scope  of  reasoning. 


Appendix  2  —  Tri-base  Agent  Implementation 


This  appendix  describes  the  tri-base  agent  implementation.  The  tri-base  agent  consists  of  two  parts,  a 
wrapper  and  a  body.  While  the  body  is  a  computational  instantiation  of  the  tri-base  acquaintance 
model  that  was  designed  within  the  first  and  the  second  phases  of  project  and  tested  in  the  third 
phase  of  the  project,  the  wrapper  has  been  developed  in  order  allow  encapsulation  of  the  tro-base 
agent  within  the  ProPlanT  multi- agent  system.  The  wrapper  translates  messages  from  the  body  to  the 
low-level  communication  format  and  vice-versa.  The  wrapper  and  the  tri-base  body  are  written  in 
Java  language. 

Firstly  we  will  describe  implementation  of  the  Java  ProPlanT  wrapper  and  than  we  will  present  and 
comment  an  object  model  of  the  tri-base  body  (in  figures  referred  to  as  a  pma  agent). 

ProPlanT  Communication 

The  agent  (wrapper)  must  communicate  in  TCP-IP  protocol.  Every  agent  is  uniquely  identified  by 
the  IP  address  and  port.  Every  agent  has  also  its  symbolic  name. 

Messages  that  are  sent  between  agents  can  be  in  two  format,  control  and  KQML.  Control  messages 
allow  technical  around  for  community  (born  and  dead  of  agents).  KQML  messages  are  used  to  body 
of  agent.  Figure  7  describe,  which  messages  are  sent  between  levels.  Notice,  that  body  of  agent  can 
process  only  KQML  messages  and  also  can  sent  only  KQML  messages  again. 


Agent  1  Agent  2 


Figure  7  -  Communication  schema  between  two  agents 

How  to  write  your  own  agent 

In  order  to  build  your  own  agent  we  recommended  to  extend  class  proplant .  wrapper .  Wrapper 
and  override  its  method  processMessage  ( KQMLMe s  s age  kqmlMessage) 

You  can  also  extend  class  proplant .  Agent  and  override  methods  that  are  discerned  by 
performative. 

•  processSubscribe (KQMLMessage) 

•  processRegister (KQMLMessage) 

•  processUnRegister (KQMLMessage) 

•  processAchieve (KQMLMessage) 

•  processUnAchieve (KQMLMessage) 

•  processAdvertise (KQMLMessage) 

•  processEvaluate (KQMLMe s sage) 

•  processSorry (KQMLMessage) 
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•  processReply (KQMLMessage) 

•  processReady (KQMLMessage) 

But  if  you  need  to  process  some  other  performs,  you  must  override  method 

processMessage (KQMLMessage) . 

Processing  results  in  a  new  KQML  message  that  must  be  sent  to  some  other  agent.  You  must  use 
method  sendMes sage (String  agentName,  KQMLMessage  kqmlMessage) .  If  you  need  to  send  a 
message  to  all  agents  in  community,  you  can  use  method  sendBroadcastMessage  ( KQMLMe s s age ) . 

For  demonstration  example  can  look  at  My  Agent .  java. 

Installation  and  Compilation  of  Java  Sources 

If  you  want  to  create  programs  in  Java,  you  need  a  Java  Development  Kit  1.2.2,  which  you  can 
download  from  http://java.sun.com/j2se.  If  you  don't  know,  which  JDK  you  have  already 
installed,  execute  from  command  line  c :  >  java  -version. 

Compilation  of  your  programs  is  easy.  Execute  from  the  command  line  c:>javac  my  class,  java. 
This  create  file  myclass . class  that  can  be  executed  as  c:>java  myclass.  Because  is  user- 
unfriendly  to  write  your  code  in  the  notepad  and  compile  it  from  the  command  line,  you  can  use 

Borland  JBuilder  or  Forte. 

Wrapper 

The  Wrapper  is  consisted  of  five  packages. 

•  proplant 

•  proplant .util 

•  proplant . wrapper 

•  proplant . messages . kqml 

•  proplant . messages . control 

Most  important  is  the  class  proplant .  wrapper .  Wrapper.  This  class  must  extend  the  body  of  every 
agent. 

Package  proplant 

Package  proplant  contains  auxiliary  classes 

•  proplant .  TaskName  —  property  taskName  with  it's  set-get  methods 

•  proplant  .AgentName  —  property  agentName  with  it’s  set-get  methods 

•  proplant .  TaskAgent  —  property  taskName  and  agentName 
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proplant .  Agent  —  extended  by  proplant. Wrapper  —  an  empty  agent 


Figure  8  -  Class  diagram  of  package  proplant 

Package  proplant. messages. kqml 

This  package  contains  four  classes.  The  most  important  is  the  class 

proplant  .messages .  kqml  .KQMLMes sage.  This  class  provides  parser  and  builder  of  KQML 
message.  Class  proplant  .messages .  kqml .  Content  provides  parser  and  builder  of  the  content 
KQML  message.  It  is  supposed  that  content  is  in  lisp  list  format.  Class 

proplant  .message .  kqml .  Trust  provides  elementary  information  included  in  the  content. 
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PropertyTable 
(from  util) 


*PropertyTable() 

*PropertyTable() 

*toString() 

■toListQ 


A 


KQMLMessage 


*KQMLMessage() 

*KQMLMessage() 

'parse() 

^KQMLMessage() 

*KQMLMessage() 

%etPerform() 

%etSenderO 

%etReceiver() 

%etContent() 

%etContent() 

%etReply_with() 

^setReply_with() 

;-'setReply_with() 

%etln_reply_to() 

%etln_reply_to() 

%etln_reply_to() 

%etLanguage() 

^getPerform() 

■^■getSenderO 

^getReceiver() 

^getContentQ 

^getReply_with() 

^'getln_  _reply_to() 

'^'getLanguage() 

^getMessage() 

^oStringQ 


Content 


*Content() 

*buildContents() 

%>arse() 

%)ars  e() 

^Content() 

%etStartTime() 

^setEndTime() 

%etOperationCost() 

^getStartTime() 

^getEndTime() 

*getOperationCost() 

%etStartTime() 

^setEndTime() 

%etOperationCost() 

*setTrust() 

^getContent() 

^setTaskName() 

l*'getTaskName() 

ltoList() 


Trust 


*Trust() 

*Trust() 

*Trust() 

*Trust() 

*Trust() 

.^trusting() 

%etOperationCost() 

%etStartTime() 

%etEndTime() 

%etOperationCost() 

%etStartTime() 

%etEndTime() 

‘^getStartTimeO 

■^■getEndTimeO 

HgetOperationCostO 


Figure  9  —  Class  hierarchy  of package  proplant. mess  ages. kqml 
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Package  proplant,  mess  ages. control 

This  package  contains  class  proplant  .messages  .  control .  ControlMes sage  that  provide  parser 
and  builder  of  control  message.  Type  of  command  is  adjustment  by  the  class 

proplant  .messages .  control .  Commands  and  type  of  message  by  the  class 
proplant .message . control . Types. 


ControlMessage 


"^ControlMessage() 

^ControlMessage() 

^getTypeO 

^getCommandO 

^■getNameO 

IgetlPO 

■^■getPortO 

(setTypeO 

^setTypeO 

■^setCommandO 

^setCommandO 

*setName() 

♦setlPO 

■^setPortO 

"^setPort() 

-■getMessageO 

^toStringO 


Commands 


i  CONFIRM_YES  :  char  =  '1' 
i  CONFIRM_NO  :  char  =  '0' 

I  START  :  char  =  'G' 
i  REGISTER  :  char  = 'H' 

I  ADDRESS:  char  =  T 
i  UNREGISTER:  char  =  'J' 

I  KILL:  char  = 'K' 
i  KILL  ALL  :  char  = 'L' 


Types 
ACKNOWLEGE  :  char  =  ' 
COMMAND  :  char  = '#' 


♦Types  () 


PropertyTable 

(from  util) 

ZAl 


Figure  10  -  Class  diagram  of  the  package  proplant.mes sages,  control 


Package  proplant. uti I 

This  package  contains  only  one  class  proplant  .util  .PropertyTable  that  is  used  as  a  parent  of 
another  classes. 


PropertyTable 

^PropertyTable() 
vPropertyTable(list :  List) 
(toString() :  String 
♦toList() :  List 

- D> 

Hashtable 

(from  util) 

Figure  1 1  -  Class  diagram  of  the  package  proplant,  util 


28 


Package  proplant. wrapper 

The  class  proplant . wrapper . Wrapper  uses  the  class  proplant  .wrapper .  Console  as  a  list  of 
messages.  Wrapper  writes  into  the  console  input  and  output  KQML  messages.  User  can  later  analyze 
this  log.  The  class  proplant .  wrapper .  PhoneBook  is  a  list  of  proplant  .wrapper  .Agent  Info.  It  is 

used  for  translating  network  addresses  to  agent  names  and  vice-versa.  In  property  observerName 
there  is  stored  name  of  agent,  to  which  copies  of  outgoing  messages  are  sent. 

The  basic  building  block  of  the  wrapper  is  in  the  method  run.  The  thread  is  blocked  until  some 
socket  request  is  fired.  If  incoming  message  is  in  the  control  format,  than  the  wrapper  process  it  by 
private  method  proces sControlMes sage  (KQMLMes sage) .  If  incoming  message  is  in  KQML 
format,  the  wrapper  writes  this  message  into  an  input  queue  and  blocks  itself  until  next  request  is 
fired.  Another  thread  InputQueue  reads  messages  from  the  input  queue  and  fires  method 
proce s sMe s sage  (KQMLMes sage) .  So  messages  are  processed  asynchronously.  When  agent  call 
method  sendMessage  (String  agentName,  KQMLMessage  kqmlMessage),  new  instance  of 
OutputThread  is  created,  that  send  message  throw  network.  Every  request  for  sending  message 
creates  new  thread.  So  all  outgoing  messages  are  sent  asynchronously. 

If  you  want  to  listens  to  some  events  e.g.  for  visualization,  you  must  create  class  that  implements 

proplant  .wrapper  .WrapperLi st ener  interface  and  connect  it  to  wrapper  by 

setWrapperListener (WrapperListener) . 

New  wrapper  is  create  e.g 

Wrapper  wrapper  =  new  Wrapper ("agentName",  "localhost",  1000); 
wrapper . register ( ) ; 
wrapper . start  ( ) ; 

Method  wrapper .  harakiri  ( )  unregister  and  destroy  itself. 
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Recomendation 

In  any  processXXX(KQMLMessage  message)  method  you  need  often  to  get  content  from 
KQMLMessage.  Mehod  message .  get  Content  ()  returns  content  as  String,  but  you  need  it  in  KIF 
(lisp)  format.  If  you  assume,  that  the  content  contains  only  one  list,  you  can  use  static  method 

Content .parse (String) . 


Content  content  =  Content . parse (message . getContent ( ) ) ; 

If  you  assume,  that  content  contain  more  then  one  list,  you  must  use  static  method 
Content  .buildContents  (String)  that  return  Enumeration  of  contents. 


Enumeration  enum  =  Content .buildContent (message . getContent ()) ; 
while  (enum. hasMoreElements () )  { 

Content  content  =  (Content) enum. nextElement () ; 


} 
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If  you  have  an  instance  of  class  proplant  .messages .  kqml .  Content,  you  get  all  properties  by 
method  getXXXQ; 


String  taskName 
long  operationCost 
long  startTime 
long  endTime 


=  content . getTaskName ( ) ; 
=  content . getOperationCost ( ) ; 

=  content . getStartTime ( ) ; 

=  content . getEndTime ( )  ; 


If  you  need  to  create  new  content,  you  can  use  setXXX(value)  methods 

Content  content  =  new  Content ( ) ; 
content . set TaskName ("car" ) ; 
content . set StartTime (100)  ; 
content . setEndTime (200) ; 
content . setOperationCost (300)  ; 


If  you  need  to  create  and  send  KQMLMessage,  you  can  use  setXXX(value)  methods 

KQMLMessage  kqmlMessage  =  new  KQMLMessage () ; 
kqmlMessage . setPerf orm (Performs . EVALUATE) ; 
kqmlMessage . set Content (content) ; 
kqmlMessage . setReply_with (13) ; 
sendMes sage ("dealer",  kqmlMessage) ; 


Tri  base  agent 

Tri  base  agent  body  consists  of  the  task  base,  the  state  base  and  the  cooperation  base.  In  the  task 
base  is  stored  static  knowlede  (task  section)  and  plans  (plan  section).  State  base  consists  of  states  of 
another  agents  (agent  states)  and  of  list  of  tasks,  which  were  achieved  (achieves).  Cooperation  base 
contains  information  about  agents,  which  are  cooperating  with  the  agent  (subscribers). 

Tri  base  agent  is  packaged  in  package  proplant.pma.  Documentation  you  can  browse  here.  Every 
base  has  its  own  package  —  proplant.pma.taskbase,  proplant.pma.coopbase  and 
proplant.pma. statebase.  Task  base  is  consists  of  two  parts  —  proplant.pma.taskbase.tasksection  and 
proplant.pma. taskbase.plansection.  Also  state  base  has  two  parts  —  proplant.pma. statebase.agentstates 
and  proplant.pma.statebase.achieves. 
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figure  13—  Class  diagram  of  package  proplant.pma 

Task  base  in  XML  format 

The  PMA  has  its  knowledge  stored  in  the  taskbase  file.  DTD  description  is  in  file  proplant.dtd.  The 
task  base  file  contains  list  of  xml  files.  Every  xml  file  descripts  one  task. 

Example:  management.tb  and  k_port.xml 


<?xml  version="l . 0M?> 

< ! DOCTYPE  Task  SYSTEM  /proplant . dtd"> 

<Task> 


<TaskName>  compres_port  </TaskName> 


<SubTasks> 


<TaskName>  material_c_p  </TaskName> 

<TaskName>  product ion_c_p  </TaskName> 

<TaskName>  dispatching_c_p  </TaskName> 

</SubTasks> 

<Orders> 

<OrderItem> 

<FirstTask>  material_c_p  </FirstTask> 
<SecondTask>  product ion_c_p  </SecondTask> 

< /Order Item> 

<OrderItem> 

<FirstTask>  product ion_c_p  </FirstTask> 
<SecondTask>  dispatching_c_p  </SecondTask> 
< /Order Item> 

</Orders> 


</Task> 


Appendix  3  —  Tri-base  Agent  Demonstration 

This  appendix  gives  guidelines  on  how  to  run  and  reconstruct  experiments  described  in  the  report. 
If  you  don't  have  JVM  installed,  download  it  from  http :  // jsp2  .  java .  sun .  com/ j2se/l .  3/ jre 


Step  1  : 

change  directiory  to  Proplant /Demo 
run  f  acil .  exe 

Step  2: 

run  agentfactory .  exe  and  in  menu  fire  CreateAgents. 


Step  3: 

Find  the  agent  Bubik  (Java  agent  factory  with  coffee  icon). 

Make  Bubik  agent  to  send  message  to  Management  agent.  Fill  tab  with  parameters  bellow. 

Message:  perform  =  ACHIEVE 

reciever  =  Management 

content  =(  (compres_port) 

(start -time  0) 

(end-time  1000) 

(operation-cost  1000) ) 

reply  with  =  13 

in  Observer  agent  you  can  see  community  structure.  In  a  few  seconds  Management  sends 

back  to  Bubik  message  with  perform  reply  (this  you  can  see  in  Bubiks  console). 


Step  4: 

In  Observer  you  can  see  community  structure  and  links  with  in-out  messages.  In  a  few  time 
Management  send  back  to  Bubik  message  with  perform  REPLY  (this  you  can  see  in  Bubik's 
console  tab). 

It  shows  as 

in : 

(REPLY 

: SENDER  Management 
: RECEIVER  Bubik 
: CONTENT  ( (compres_port) 

(end-time  29) 

(start -time  0) 

(operation-cost  322) ) 

: REPLY— WITH  4 
: IN— REPLY— TO  13 
: LANGUAGE  KIF) 


34 


Also  agent  Management  has  info  agout  this  transaction.  Click  on  agent  Management  -  tab 
State  base  -  subtab  Task  states. 

Property  Status  informs,  if  the  agent  received/ sent  REPLY  message. 


Step  5 : 

Close  facilitator  -  this  close  all  community. 


How  run  java  agents 


Empty  agent  (only  wrapper) 

run  java  -cp  proplant.zip  proplant. wrapper. Wrapper  agentName  facilitatorHostName 
facilitatorPort 


example:  java  -cp  proplant.zip  proplant. wrapper. Wrapper  Smith  localhost  1000 


PM  A  agent  (tri-base) 

run  java  -cp  proplant.zip  proplant.pma.PMA  agentName  taskBaseFile  facilitatorHostName 
facilitatorPort 


example:  java  -cp  proplant.zip  proplant.pma.PMA  Management  Pma/Management.tb 
localhost  1000 

Broadcast  agent 

run  java  -cp  proplant.zip  proplant.broadcast.BroadcastAgent  taskBaseFile 
facilitatorHos tN ame  facilitatorPort 


example:  java  -cp  proplant.zip  proplant.broadcast.BroadcastAgent  Management 

Pma/Management.tb  localhost  1000 

Factory 

some  agent  run  on  the  same  VM 

run  java  -cp  proplant.zip  proplant. factory. Factory  factoryConfigFile  facilitatorHostName 
facilitatorPort 


factoryConfigFile  —  xml  config  file 


example:  java  -cp  proplant.zip  proplant. factory. Factory  factory.xml  localhost  1000 
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WRITING  AGENTS  IN  JAVA 


Description 

Agent  in  multi-agents  system  has  generaly  two  parts,  wrapper  and  core.  Wraper  translate 
messages  from  core  to  low-level  comunication  format  and  vice-versa.  This  white  paper 
describe  wrapper  for  proplant  agents  written  in  Java. 


Requirements 

Agent  (wrapper)  must  comunicate  by  TCP-IP  protokol.  So  every  agnet  is  unambiguous 
intended  by  his  IP  address  and  port.  Every  agent  has  also  his  name  that  is  assigned  to  his 
network  address. 


Messages  that  are  sent  between  agents  are  in  two  format,  control  and  KQML.  Control 
messages  allow  technical  upcountry  for  comunity  (born  and  dead  of  agents).  KQML 
messages  are  intended  to  core  of  agent. 


Agent  1  Agent  2 

Picture  1-  Communication  schema  between  two  agents 


Wrapper  and  empty  core  are  written  in  Java  language.  Picture  1  describe,  which  messages 
are  sent  between  levels.  Notice,  that  core  of  agent  can  process  only  KQML  messages  and 
also  can  sent  only  KQML  messages  again. 
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How  write  my  own  agent 

Recommendation  way,  how  build  your  own  agent  is  extend  class 

proplant .  wrapper .  Wrapper  and  Override  its  method  processMessaqe  (KQMLMessaqe 
kqmlMessaqe) 

You  can  also  extend  class  proplant  .Agent  and  override  methods  that  are  discerned 
by  perform 

•  processSubscribe (KQMLMessaqe) 

•  processReqister (KQMLMessaqe) 

•  processUnReqister (KQMLMessaqe) 

•  processAchieve (KQMLMessaqe) 

•  processUnAchieve (KQMLMessaqe) 

•  processAdvertise (KQMLMessaqe) 

•  processEvaluate (KQMLMessaqe) 

•  processSorry (KQMLMessaqe) 

•  processReply (KQMLMessaqe) 

•  processReady (KQMLMessaqe) 

But  if  you  need  process  some  other  performs,  you  must  override  method 

processMessaqe (KQMLMessaqe) . 

As  affect  of  processing  is  often  new  KQML  message  that  must  be  sent  to  some  other  agent. 
For  this  account  you  have  no  choice.  You  must  use  method  sendMessage  (string 
agentName,  KQMLMessage  kqmlMessaqe) .  If  you  need  send  message  to  all  agents  in 
community,  you  can  use  method  sendBroadcastMessaqe  (KQMLMessage)  . 

Demonstration  example  you  can  look  throw  atMvAqent.iava. 

Documentation 

All  code  codumentation  you  can  browse  here . 
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Installation  and  compilation  java  sources 

If  you  want  create  programs  in  java,  you  need  Java  Development  Kit  1.2.2,  which  you  can 
download  from  http://1ava.sun.com/12se.  If  you  don't  know,  which  JDK  you  have  already 
installed,  try  execute  from  comand  linec:>java  -version. 

Compilation  your  programs  are  easy.  Execute  from  command  line  c:>javac 
myciass .  java.  This  create  file  myclass. class  that  can  be  exetuted  as  c:>java  myciass. 
Becase  is  user  unfriendly  write  your  code  in  notepad  and  compile  it  from  comand  line,  you 
can  use  Borland  JBuilder,  which  is  free  and  you  can  download  it  from 
http://www.borland.com/downloads. 


Wrapper  detailed 


Class  proplant .  wrapper .  Wrapper  use  Class  proplant .  wrapper .  Console  as  a  list  of 
messages.  Wrapper  writes  into  console  input  and  output  messages.  User  can  later  analyze 
this  log.  Class  proplant .  wrapper  .  PhoneBook  is  list  of  proplant .  wrapper  .  Agent  Inf  o.  It  is 
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used  for  translating  network  addresses  to  agent  names  and  vice-versa.  In  property 
observerName  is  stored  name  of  agent,  to  which  are  sent  copies  of  outgoing  messages. 

Base  of  wrapper  is  in  method  run.  Thread  is  blocked  until  some  socket  request  is 
fired.  If  incoming  message  is  in  control  format,  than  wrapper  process  it  by  method  private 
method  processControiMessage  (KQMLMessage) .  If  incoming  message  is  in  KQML  format, 
wrapper  write  this  message  into  input  queue  and  blockself  until  next  request  is  fired. 
Another  thread  inputQueue  reads  messages  from  input  queue  and  fires  method 
processMessage  (KQMLMessage) .  So  messages  are  processed  asynchronously  from  accepting 
requests.  When  agent  call  method  sendMessage  (String  agentName,  KQMLMessage 
kgmiMessage) ,  is  create  new  instance  of  OutputThread  that  send  message  throw  network. 
Every  request  for  sending  message  creates  new  thread.  So  all  outgoing  messages  are  sent 
asynchronously. 

If  you  want  listens  some  evens  e.g.  for  visualization,  you  must  create  class  that 
implements  proplant  .wrapper . wrapperListener  interface  and  connect  it  to  wrapper  by 

setWrapperListener (WrapperListener ) . 

New  wrapper  is  create  e.g 

Wrapper  wrapper  =  new  Wrapper ("agentName",  "localhost",  1000); 
wrapper . register ( ) ; 
wrapper . start ( ) ; 

Method  wrapper .  harakiri  ( )  unregister  and  destroy  self. 


Recomendation 

In  any  processXXX(KQMLMessage  message)  method  you  need  often  get  content  from 
KQMLMessage.  Mehod  message .  getcontent  ( )  return  content  as  String,  but  you  need  it  in 
KIF  (lisp)  format.  If  you  assume,  that  content  contain  only  one  list,  you  can  use  static 
method  Content .parse (String)  . 

Content  content  =  Content . parse (message . getContent ()) ; 

If  you  assume,  that  content  contain  more  then  one  list,  you  must  use  static  method 
Content . buildContent s  (String)  that  return  Enumeration  of  contents. 


Enumeration  enum  =  Content . buildContent (message . getcontent ()) ; 
while  (enum. hasMoreElements ( ) )  { 

Content  content  =  (Content ) enum. nextElement ( ) ; 


If  you  have  at  last  instance  of  class  proplant  .messages .  kgmi .  content,  you  get  all 
properties  by  method  getXXXQ; 


String  taskName 
long  operationCost 
long  startTime 
long  endTime 


=  content . getTaskName ( )  ; 

=  content . getOperationCost  () ; 
=  content . getStartTime () ; 

=  content . getEndTime ( ) ; 


If  you  need  create  new  content,  you  can  usesetXXX(value)  methods 


Content  content  =  new  Content  (); 
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content . setTaskName ("car") ; 
content . set St art Time ( 100 ) ; 
content . setEndTime (200 ) ; 
content . setOperationCost (300) ; 

If  you  need  create  and  send  KQMLMessage,  you  can  usesetXXX(value)  methods 

KQMLMessage  kqmlMessage  =  new  KQMLMessage () ; 
kqmlMessage . setPerf orm (Performs . EVALUATE) ; 
kqmlMessage . setContent (content) ; 
kqmlMessage . setReply_with ( 13 ) ; 
sendMessage ("dealer",  kqmlMessage) ; 
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KQML  package 


PropertyTable 

(from  util) 


~C>  ^PropertyTable()  <d“ 
^PropertyTable() 
JtoString() 

^toListQ 


KQMLMessage 


^KQMLMessage() 
^KQMLMessage() 
Sparse  () 

^KQMLMessage() 

^KQMLMessage() 

^setPerformO 

^setSender() 

^setReceiver() 

^setContent() 

^setContent() 

^setReply_with() 

^setReply_with() 

^setReply_with() 

*setln_reply_to() 

^setln_reply_to() 

;$setln_reply_to() 

^setLanguage() 

^getPerform() 

^getSender() 

^getReceiver() 

^getContent() 

^getReply_with() 

^getln_reply_to() 

%etLanguage() 

^getMessage() 

^oStringO 


Content 


^Content() 

^buildContents() 

%arse() 

*parse() 

^Content() 

^setStartTime() 

^setEndTime() 

^setOperationCost() 

^getStartTime() 

^getEndTime() 

^getOperationCost() 

^setStartTime() 

^setEndTimeO 

^setOperationCostO 

^setTrust() 

^getContent() 

^setTaskNameO 

^getTaskNamef) 

■toList() 


Trust 


*Trust() 

*Trust() 

^Trust() 

*Trust() 

^Trust() 

^trusting() 

^setOperationCost() 

^setStartTime() 

*setEndTime() 

^setOperationCost() 

^setStartTime() 

*setEndTime() 

*getStartTime() 

^getEndTime() 

^getOperationCostQ 


Picture  2  -  Class  hierarchy  of  package  prop  Ian  t.  messages,  kg  ml 
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PMA  agent 


Picture  3  -  PMA  agent  association  diagram 


